Re: [Uta] getting back to UTA and injecting clue

[Stephen Farrell <[e-mail]>]

Eliot is correct IMO.

S

On 03/17/2014 01:47 PM, Eliot Lear wrote:
> I'd like suggest a change of direction for this discussion.  If we get a
> bit more specific about the use cases, it will become clear when it is
> reasonable to make use of fully authenticated (bidirectional) TLS; when
> it might make sense to do *some* form of opportunistic keying and when
> it makes sense to do nothing (there are, I think some limited cases for
> not encrypting).  Keith well knows the situation with email, and in fact
> the draft that he and Chris seems like a good place to go back to.
> 
> Keeping in mind that the ecosystem for email clients is extremely
> diverse, ranging from complex UIs to PHP modules to age-old shell
> scripts, and from private environments to the wild and woolly Internet,
> if our goal is to get TLS to be the default then one has to ask this
> question: why is it not already so?  The answer might be a useful
> addition to the draft.
> 
> So for instance, if clients are meant to speak TLS either by default or
> all the time, what does it look like on the server end in an enterprise,
> we know that enterprises have great difficulty managing certificates,
> both in terms of initial configuration and ongoing maintenance.  Some of
> it is just not wanting to go to a CA for a cert again and again.  Some
> of it is simply keeping track of what expires when.
> 
> Also, perhaps there are some enterprise environments where DANE is
> perhaps more feasible than in the wild Internet.  The authors take this
> into account in Section 2.2.12 (I think), but perhaps some support text
> about when and how DANE is used would prove useful.  It might also
> motivate those who are writing MUAs to actually implement DANE.
> 
> Anyway, hopefully you'll find this food for thought.
> 
> Eliot
> 
> On 3/17/14, 1:30 PM, Michael Richardson wrote:
>> To a pervasive monitor that sees/intercepts traffic only the middle
>> (i.e. they did not monitor/intercept DNS/OCSP/etc. requests),
>> OK enabled traffic is hard to distinguish from pre-configured security.
>>
>> As such, the more crypto traffic there is, the harder it is to decide
>> which traffic can be MITM without detection.
>>
>> (IKE/IPsec is slightly better in terms of traffic analysis of
>> crypto-identities and port numbers here)
>>
>>> That kind of "if we do something, some other bad thing may happen"
>>> argument is utterly bogus IMO.
>> Or, "better is the enemy of good enough".
>> Throughout the over-long review of 4322, I came to understand that the people
>> who kept saying that were the NSA pawns/moles.  Pawn, because I came to
>> understand that many of them were unaware of what they were doing.
>>
>> --
>> Michael Richardson <[e-mail]>, Sandelman Software Works
>>  -= IPv6 IoT consulting for hire =-
>>
>>
>>
>>
>>
>> _______________________________________________
>> Uta mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/uta
> 
> 
> 
> 
> _______________________________________________
> Uta mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/uta
>