Subject: Re: [lemonade] QUICKSTART update

From: Chris Newman <[email-masked]>
Date: Wed, 16 May 2007 14:23:54 -0700

Tony Finch wrote on 4/19/07 19:56 +0100:
> draft-fanf-smtp-quickstart-a-00 and draft-fanf-smtp-quickstart-b-00 have
> been published. I've separated it into two documents to make the two
> different profiles clearer. I prefer the -B profile but I'd like opinions
> from others about the trade-off between complexity and effectiveness.

Taking off my area director hat, and speaking as a technical participant:

It's my opinion that the way profile B interacts with the TLS layer is 
problematic for implementations.  The server code I work on uses the NSS 
(Mozilla) SSL/TLS library.  While it would be possible to implement profile B 
using that SSL/TLS library, it's very difficult as it requires writing a 
special NSPR I/O layer that slots below the SSL stack and deals with the 
STARTTLS server response after the client has activated the TLS state machine. 
Requiring tricky code like that for security integration is never a good idea.

The problem is that activating the TLS layer is a software state change that 
takes over both socket directions.  So it really shouldn't happen until the 
only subsequent protocol will be TLS packets.  Having secure and non-secure 
packets in-transit at the same time is not a good idea from a state management 
point of view.

If you want additional input on the topic, I suggest asking on the TLS WG 
mailing list.

                - Chris

_______________________________________________
lemonade mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/lemonade
Supplemental Web Site:
http://www.standardstrack.com/ietf/lemonade

---

From: Tony Finch <[email-masked]>
Date: Thu, 17 May 2007 17:42:51 +0100

On Wed, 16 May 2007, Chris Newman wrote:
> problematic for implementations. [...]
>
> The problem is that activating the TLS layer is a software state change
> that takes over both socket directions.  So it really shouldn't happen
> until the only subsequent protocol will be TLS packets.  Having secure
> and non-secure packets in-transit at the same time is not a good idea
> from a state management point of view.

Thanks for looking into this, and especially for having a go at
implementing it. I have to agree even though it makes me sad that this
means it probably isn't possible to safely eliminate the last RTT. In the
next revision I'll replace pipelined STARTTLS with QTLS, and make sure
that the cleartext/TLS boundary is simple.

Tony.
-- 
f.a.n.finch  <[email-masked]>  http://dotat.at/
VIKING NORTH UTSIRE SOUTH UTSIRE: NORTHERLY BACKING SOUTHERLY 4, INCREASING 5
TO 7, PERHAPS GALE 8 LATER. SLIGHT, BECOMING MODERATE OR ROUGH. RAIN LATER.
MODERATE OR GOOD.